<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<html>
  <head>
    <title>Validation</title>
    <link href="../style.css" rel="stylesheet" type="text/css">
  </head>
  <body>
  <div class="header">
<h1>QuickFIX/J User Manual</h1>
</div>

    <H2>Validation</H2>
  <p>

  QuickFIX will validate and reject any messages that do not conform to the FIX specifications.
  This means that it will reject any poorly formed messages without bothering you at the application
  level. But there is an extra piece to validation. QuickFIX can also dynamically load an XML
  definition file for each session which it will use to validate if a message is of the right type,
  if it contains unsupported fields, if required fields are missing etc... And it will do this all without
  you needing to do any extra work at the application level.
  </p>
  <p>
  QuickFIX comes with several definition files. These are <code>FIX40.xml</code>, <code>FIX41.xml</code>,
  <code>FIX42.xml</code>, <code>FIX43.xml</code> and <code>FIX44.xml</code>. These are directly generated off their respected fix specification documents.
  But the power comes in modifying these documents or creating new ones for your specific needs.
  <p>

  <p>
  If, for instance, you need to define a FIX spec for a sell side application.  Why not define the
  spec in XML and then just publish the XML file to your clients! Not only is your FIX spec fully documented
  in a machine and human readable format, but you can guarantee that the documentation is 100%
  accurate because it is actually <em>defining</em> and not just reflecting reality.
  </p>
  <p>
  And if XYZ corp needs some special fields added to their session but you don't want to expose
  them to anyone else, fine. Create XYZ.xml, load it up with the session and keep everyone else
  using the normal definintion file. Now XYZ can send their user defined fields but they will be rejected
  for anyone else.
  </p>
  <p>
  The skeleton of a definition file looks like this.
  </p>

  <PRE class="code">
  &lt;fix major="4" minor="1">
    &lt;header>
      &lt;field name="BeginString" required="Y"/>
      ...
    &lt;/header>
    &lt;trailer>
      &lt;field name="CheckSum" required="Y"/>
      ...
    &lt;/trailer>
    &lt;messages>
      &lt;message name="Heartbeat" msgtype="0" msgcat="admin">
        &lt;field name="TestReqID" required="N"/>
      &lt;/message>
      ...
      &lt;message name="NewOrderSingle" msgtype="D" msgcat="app">
        &lt;field name="ClOrdID" required="Y"/>
        ...
      &lt;/message>
      ...
    &lt;/messages>
    &lt;fields>
      &lt;field number="1" name="Account" type="CHAR" />
      ...
      &lt;field number="4" name="AdvSide" type="CHAR">
       &lt;value enum="B" description="BUY" />
       &lt;value enum="S" description="SELL" />
       &lt;value enum="X" description="CROSS" />
       &lt;value enum="T" description="TRADE" />
     &lt;/field>
     ...
    &lt;/fields>
  &lt;/fix></PRE>
  <p>
  The validator will not reject conditionally required fields because the rules for them are not
  clearly defined and are often debatable. QuickFIX will reject a conditonally required field when
  you try to pull it out in your <code>fromApp</code> function if you try to get a field that is not there.
  <div class="footer">More information at <a href="http://www.quickfixj.org/">www.quickfixj.org</a></div>

  </body>
</html>